home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Jul 88 / The Crazy Limits Blues 7⁄1 < prev   
Encoding:
Text File  |  1991-03-06  |  2.1 KB  |  45 lines  |  [TEXT/GEOL]

  1. Item    1543017                         1-July-88        16:54
  2.  
  3. From:   BURBECK.S                       Burbeck, Steve
  4.  
  5. To:     D0989                           G-Bar Partnership, Dev, M Bentley
  6.  
  7. cc:     MACAPP$                         MacApp Interest List
  8.  
  9. Sub:    The Crazy Limits Blues
  10.  
  11. Mike,
  12.  
  13. I was speaking about long range issues from an Object-Oriented Programing
  14. purist perspective.  MacApp is a great product and I don't consider the 4096
  15. entry jump table limit to be a serious problem at present.  The intent of my
  16. link was to point out that the jump table limit will eventually conflict with
  17. the best OOP practices.  I wanted to stimulate discussion about the issue (and
  18. perhaps about good OOP design practices as well), not incite panic.
  19.  
  20. Niether the Mac, nor MacApp is incapable of being used with large applications.
  21.  For instance, "Author/Editor" is a 497K application that was written with
  22. MacApp.  Its developers only occasionally ran into the 4096 jump table limit
  23. with debugging turned on.  With debugging off, they are nowhere near the limit.
  24.  
  25. Limits of one sort or another are present in every hardware architecture, OS,
  26. language, editor, and application.  As David Goldsmith pointed out, every
  27. designer has to make hard choices; those choices often result in limits on the
  28. hardware or software we design.  [Of course the limits we ourselves impose on
  29. our users are rational, and those imposed upon us by others are arbitrary :-) ]
  30.  Some limits weigh heavily on us, some are taken for granted and many escape
  31. our attention entirely (until they bite us with a bug).
  32.  
  33. The jump table is used for method dispatch.  So the limit is on the total
  34. number of methods.  One work around is to use fewer larger methods.  Obviously
  35. that is not as pleasant as if there were no limit, but it is a lot more
  36. pleasant than abandoning MacApp entirely because there is a limit on the number
  37. of methods.  After all, you can freely intermix methods with regular procedures
  38. and functions.  So there can be a smooth continuum between the two extremes of
  39. everything-a-method to no-methods.  Your position on that continuum is up to
  40. you.
  41.  
  42. Steve Burbeck
  43.  
  44.  
  45.